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Errors  in  a  software  design  can  be  detected  early  on  by  analyzing  a  formal  model 
expressed  in  a  specification  language  such  as  Z.  Since  software  designs  tend  to  involve 
infinite  (or  at  least  very  big)  state  spaces,  it  has  been  assumed  that  this  analysis  cannot  be 
automated.  Consequently,  few  formal  specifications  have  been  extensively  analyzed,  and 
the  potential  for  early  detection  of  errors  has  not  been  realized. 

This  paper  argues  that,  while  proving  properties  of  designs  may  be  intractable,  detect¬ 
ing  errors  may  not  be.  State  transitions  of  an  operation  can  be  enumerated  exhaustively, 
within  a  ‘scope’  defined  by  the  user  that  places  a  bound  on  the  size  of  state  components. 
Symmetry  can  then  be  exploited  to  reduce  this  finite  state  space.  A  state  can  be  shown  to 
be  symmetrical,  in  the  context  of  the  analysis,  to  a  state  already  examined,  and  thus 
guaranteed  not  to  reveal  an  error. 

Preliminary  experiments  with  a  prototype  are  promising.  A  small  scope  often  seems 
sufficient  to  catch  errors,  and  exhibits  enough  symmetry  to  reduce  search  by  a  factor  of 
10  or  more. 
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1  Introduction 


The  remarkable  success  of  model  checking  in  analyzing  hardware  designs  raises  an 
obvious  question.  Can  the  same  technique  -  namely  massive  enumeration  of  cases  - 
be  applied  to  software  designs?  The  payoff  would  be  spectacular. 

Pioneers  of  formal  specification  realized  that  its  primary  justification  was  not  for¬ 
malism  per  se  (since,  after  all,  judicious  use  of  informal  mathematics  can  provide 
much  of  the  intellectual  benefit  with  fewer  restrictions),  but  the  opportunities  it 
opened  up  for  mechanical  analysis.  Questions  about  the  consequences  of  design  de¬ 
cisions  might  be  cast  as  theorems  and  then  answered  automatically  [GH80]. 

Unfortunately,  such  theorems  tend  to  be  undecidable.  Software,  unlike 
hardware,  is  often  designed  initially  with  the  assumption  of  unlimited  resources, 
and,  unless  these  can  be  modelled  purely  as  sets,  no  interesting  property  can  be  de¬ 
termined  effectively.  And  even  if  the  state  space  of  the  software  system  is  finite,  it  is 
usually  so  large  that  any  kind  of  naive  enumeration  is  hopeless.  A  simple  binary  re¬ 
lation  over  a  set  of  three  elements  can  have  2?  values;  take  three  such  relations  and 
the  size  of  the  state  space  already  matches  that  of  a  complex  hardware  design.  For 
these  reasons,  most  research  on  analysis  of  specifications  has  concentrated  on  theo¬ 
rem  proving,  and  the  possibility  of  automatic  analysis  by  model  checking  has  been 
dismissed  as  unrealistic;  an  idea  too  stupid  to  be  seriously  pursued. 

Checking  software  designs  by  enumerating  states  is  not,  however,  as  stupid  as  it 
may  appear,  for  three  reasons.  First,  finding  counterexamples  may  be  feasible  when 
proof  is  not.  Complete  search  of  an  infinite  state  space  is  impossible,  of  course,  so 
model  checking  will  not,  in  general,  be  capable  of  demonstrating  that  a  design  has 
a  certain  required  property.  In  practice,  however,  most  designs  contain  errors.  In 
economic  terms,  early  detection  of  errors  has  more  value  than  assurance  of  correct¬ 
ness,  which,  as  detractors  of  formal  methods  have  repeatedly  observed,  can  never 
be  guaranteed  anyway.  A  formal  specification  is  by  nature  an  abstraction  and  by  ne¬ 
cessity  partial,  so  that  the  distinction  between  high  confidence  of  a  design’s  correct¬ 
ness  and  perfect  assurance  cannot  be  maintained.  A  model  checker  that  examined 
only  a  tiny  proportion  of  the  state  space  but  found  a  high  propertion  of  errors  in 
the  design  would  be  very  useful. 

Second,  the  transition  relation  of  a  software  design  is  usually  complex  enough  to 
merit  ‘single-step’  analysis:  one  often  wants  to  determine  properties  of  a  single  exe¬ 
cution  of  some  operation.  The  behaviour  of  hardware,  on  the  other  hand,  is  usually 
viewed  over  sequences  of  simple  steps.  This  kind  of  temporal  analysis  requires,  at 
the  very  least,  a  record  of  which  states  have  been  visited;  the  size  of  this  data  struc- 
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ture  strictly  limits  the  number  of  states  that  can  be  examined.  For  a  single-step 
analysis,  the  states  can  be  generated  in  order  and  discarded. 

Third,  it  may  be  possible  to  find  ways  to  search  enormous  state  spaces.  Witness 
the  discovery  in  hardware  verification  that  a  small  binary  decision  diagram  can 
characterize  a  huge  set  of  states,  allowing  vastly  bigger  designs  to  be  checked 
[BC+90].  And  abstraction  can  sometimes  enable  even  an  infinite  space  to  be 
searched  by  partitioning  it  into  a  finite  number  of  equivalence  classes  [CGL92, 
Jac94]. 

This  paper  describes  a  model  checking  algorithm  for  analyzing  designs  written  in 
a  minimal  specification  language  intended  to  capture  the  essence  of  Z  [Spi89].  Z 
was  chosen  for  its  popularity,  because  it  is  model-based  (and  thus  more  overtly 
suited  to  model  checking  than  algebraic  languages  such  as  Larch),  and  because  it 
has  a  simple  set-theoretic  semantics  (unlike  VDM,  which  adopts  the  domains  of  de- 
notational  semantics).  The  purpose  of  the  algorithm  is  to  detect  counterexamples, 
so  the  search  is  confined  within  a  ‘scope’  that  limits  the  size  of  the  objects  that 
model  the  state.  A  single-step  property  of  a  Z  specification  amounts  to  a  logical  as¬ 
sertion,  typically  an  implication  whose  hypothesis  is  the  specification  of  an 
operation  and  whose  consequence  is  a  property  whose  truth  is  to  be  determined.  A 
counterexample  is  thus  a  binding  of  variables  (the  state  components)  to  values  (par¬ 
ticular  sets,  relations,  etc.)  for  which  this  assertion  is  false. 

The  notable  feature  of  this  algorithm  is  that  it  exploits  symmetry  in  the  state 
space.  Some  states  can  be  eliminated  from  the  search  a  priori,  since  they  are  known 
to  be  equivalent,  in  the  context  of  the  claim  being  evaluated,  to  states  that  have  al¬ 
ready  been  examined.  This  is  determined  fully  automatically  and,  unlike  techniques 
based  on  abstraction,  requires  no  hints  from  the  user.  Preliminary  experiments  indi¬ 
cate  that  exploiting  symmetry  usually  reduces  the  search  by  a  factor  of  10  or  more. 


2  Some  Examples  (and  Counterexamples) 

Consider  a  toy  telephone  system  whose  state  consists  of  two  components: 

Called:  Ph  ^  Num 
Net:  Num  — ^  Ph 

The  first  is  a  relation  that  associates  with  each  phone  zero,  one  or  more  numbers 
with  which  it  has  a  call  in  progress.  The  second  is  a  function  mapping  numbers  to 
phones.  The  set  of  active  connections  between  phones  is  a  relation 
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Conns-.  Ph  *-*  Ph 
Conns  =  Called  o  Net 

obtained  by  composing  the  state  components  as  relations.  The  actions  performed 
by  users  at  their  phones  can  be  represented  as  operations  on  the  state  of  the  system. 
To  add  a  party  with  number  n  to  a  conference  call  from  phone  p,  for  example,  one 
might  execute 

op  bridge  (p:  Ph,  n:  Nunt) 

pre  p  e  dom  Called  An  $  ran  Called 
post  Called'  =  Called  U  {(p,n)}  A  Net'  =  Net 

The  precondition  says  when  the  operation  will  succeed:  the  phone  p  must  already 
have  a  call  in  progress,  and  no  other  phone  must  be  calling  the  number  n.  Some 
other  part  of  the  specification  of  the  system  will  say  what  happens  when  the 
precondition  is  violated;  including  it  here  allows  us  (temporarily  at  least)  to  ignore 
that  complication.  The  postcondition  gives  the  effect  of  the  operation:  the  phone  p 
is  mapped  to  n  in  Called,  but  Net  is  unchanged. 

(This  specification  incidentally,  is  not  in  Z.  The  unusual  role  of  invariants  and 
preconditions  in  Z  is,  from  the  point  of  view  of  model  checking,  an  irrelevant  dis¬ 
traction;  what  matters  is  the  representation  of  the  state  in  terms  of  relations  and 
the  description  of  an  operation’s  behaviour  with  a  logical  formula.  Also,  the 
symbol  o  denotes  backward  not  forward  composition  in  Z,  contrary  to  the 
standard  usage  adopted  here.) 

Many  useful  properties  of  an  operation  can  be  expressed  as  invariants  on  the 
state.  Suppose,  for  example,  that  for  billing  purposes  we  forbid  a  phone  from  being 
both  a  caller  and  a  callee  at  once: 

invB  =  {dom  Conns  n  ran  Conns  =  0) 

To  see  whether  the  operation  is  consistent  with  this  assumption,  we  can  check  the 
formula 

invB  A  pre  A  post  =>  invB' 

where  invB'  is  the  invariant  invB  with  Conns'  substituted  for  Conns.  A 
counterexample  to  this  formula  would  yield  a  state  in  which  the  invariant  holds 
and  the  operation  can  execute  successfully  but  result  in  a  state  that  violates  the 
invariant. 

The  checker  finds  such  a  counterexample  after  examining  only  38  states: 

Called  =  {(pj,  n-^} 
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Net  =  {(ni,  Pi)} 

p  =  pi 
n  =  ni 

This  counterexample  reminds  us  that  we  forgot  the  obvious:  n  should  not  refer  to  a 
phone  already  making  a  call.  But  its  small  size  also  draws  our  attention  to  two 
more  subtle  points.  First,  we  neglected  the  possibility  that  a  phone  call  itself,  which 
we  shall  surely  want  to  rule  out.  Second,  we  never  required  that  Net  be  total,  or 
that  calls  only  be  made  to  numbers  attached  to  phones. 

Here’s  a  second  example.  The  precondition  included 

n  0  ran  Called 

with  the  intent  of  ensuring  that  we  not  connect  to  a  phone  that  has  already  been 
called  by  another  phone.  Formulating  this  as  an  invariant,  we  might  say  that  two 
different  phones  cannot  call  the  same  phone 

invC  =  ip,  p")  6  Conns  A  (p',  p")  €  Conns  =^p  =  p' 
or  equivalently  that  the  inverse  of  Conns  is  a  function 
invC  =  Conns'^  G  {Ph  — +  Ph) 

This  invariant  is  also  not  preserved,  and  after  checking  185  states,  the  checker  finds 

Called  =  {(pi,  ni),  (p2,  n2)} 

Net  =  {(^2,  Ps)’  Pi)} 

P  =  Pl 

n  =  M3 

The  essence  of  this  counterexample  is  the  value  of  Net.  A  phone  may  be  called 
through  one  of  several  numbers.  To  check  if  a  number  corresponds  to  a  phone  that 
has  been  called  it  is  therefore  not  sufficient  to  determine  that  the  number  itself  was 
not  called.  We  must  either  require  that  Net  be  injective  or  strengthen  the  precondi¬ 
tion. 

This  example,  although  far  from  a  real  specification  of  a  telephone  switch 
[MZ94],  neverthess  illustrates  some  realistic  features  of  counterexample 
generation.  First,  we  have  seen  that  quite  subtle  errors  can  be  revealed  in  small 
counterexamples;  in  all  three  cases,  considering  only  3  phones  and  3  numbers  was 
enough.  Second,  a  counterexample  has  an  immediate,  tangible  benefit.  It  can  be 
hard  to  determine,  when  a  theorem  prover  fails  to  prove  a  theorem,  what  has  gone 
wrong;  a  counterexample  leaves  little  room  for  doubt,  and  often  reveals  several 
faults  at  once. 
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The  remainder  of  the  paper  explains  how  the  search  for  a  counterexample  can 
be  drastically  reduced  by  exploiting  symmetry  in  the  state  space.  A  rough  idea  of 
how  this  works  can  be  gained  by  looking  at  some  of  the  states  that  arise  in  our  ex¬ 
ample. 

«  Figure  1  shows  a  state  just  before  execution  of  the  bridge  operation.  The  two 

graphs  depict  the  relations  Called  and  Net;  the  circles  show  the  values  of  p  and  w, 
written  over  the  nodes  of  Called  to  show  where  the  new  pair  will  appear  in  Called'. 
The  search  is  being  conducted  within  a  scope  of  three  phones  and  three  numbers. 

Suppose  we  apply  a  permutation  to  the  entire  state  that  exchanges  and  ^2, 
leaving  Called  unchanged  by  altering  Net.  The  permutation  is  therefore  a  symmetry 
of  Called  but  not  of  Net.  It  is  also,  however,  a  symmetry  of  the  entire  state,  in  the 
following  sense.  The  logical  formula  being  checked  (in  the  case  of  either  invariant 
discussed  above)  is  cast  entirely  in  terms  of  Conns,  the  product  of  Called  and  Net, 
and  Conns',  the  product  of  Called'  and  Net.  Permuting  n^  and  W2  changes  Net,  but 
neither  of  these  products,  both  of  which  include  the  pair  (p^,  p^)  regardless  of 
whether  the  intermediate  element  is  n^  or  ^2.  Having  checked  the  state  shown,  the 
symmetrical  state  with  the  value  of  Net  altered  (the  edge  moving  as  shown  to  the 
new  dotted  position)  can  therefore  be  safely  omitted  from  the  search. 

Symmetry  thus  allows  fewer  states  to  be  examined  before  discovering  a 
counterexample.  Table  1  shows  its  effect  in  reducing  the  state  space.  The  checker 
was  set  to  ignore  counterexamples  and  complete  the  search;  the  total  number  of 
states  searched  is  shown  for  different  declarations  of  the  Net  relation,  followed  by 
the  reduction  factor.  The  worst  case  is  when  Net  is  injective,  because  it  eliminates 
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Figure  1:  An  example  of  a  symmetry 
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the  symmetry  of  two  domain  elements  that  map  to  the  same  range  element. 

The  first  set  of  results  applies  to  the  checking  of  the  firstof  the  invariants 
discussed  above,  and  the  second  set  applies  to  the  second  invariant.  There  is  more 
symmetry  to  exploit  in  the  second  invariant,  because  it  does  not  relate  the  domain 
and  range  of  Conns,  which  may  thus  be  permuted  without  visible  effect. 


Type  of  Net 

Checking  invB 

Checking  invC 

#States 

Factor 

#States 

Factor 

total  function 

11,696 

11 

2002 

62 

injective  function 

16,866 

5 

3214 

27 

partial  function 

22,966 

13 

4606 

64 

arbitrary  relation 

168,984 

14 

34,492 

68 

Table  1:  Reduction  of  the  state  space  due  to  symmetry 


3  Relational  Calculus 

The  simplicity  of  Z,  and  to  a  great  extent  its  power  and  flexibility  too,  derives  from 
treating  functions,  mappings  and  sequences  uniformly  as  sets  of  pairs  —  that  is,  rela¬ 
tions.  Rather  than  describing  the  checking  of  Z  directly,  we  shall  instead  consider 
formulae  in  a  much  simpler  relational  language.  This  exposes  the  fundamental 
issues  by  stripping  away  syntactic  niceties  and  makes  the  algorithm’s  application  to 
similar  languages  (such  as  AMN)  more  apparent.  The  language  may  also  turn  out 
to  be  a  good  intermediate  language  into  which  Z  can  be  translated  prior  to 
checking.  It  is  based  on  the  relational  calculus  given  its  current  form  by  Tarski  and 
others  (and  nicely  summarized  in  Chapter  2  of  [SS93]). 

The  language  is  purely  relational:  there  are  no  sets  or  atoms.  A  relation  is  binary, 
but  may  be  heterogeneous  and  thus  has  a  type  (iS,T).  When  we  give  a  model  later, 
we  will  interpret  S  and  T  as  the  sets  from  which  the  domain  and  range  elements  are 
drawn  respectively.  Basic  types  such  as  S  and  T  are  distinct;  there  is  no  subtyping. 
Nor  may  the  elements  of  S  and  T  themselves  be  relations:  the  language  is  strictly 
first-order.  We  shall  assume  that  a  formula  is  coupled  with  a  type  declaration  that 
assigns  a  type  to  each  relation  variable,  and  that  the  formula  itself  is  well-typed. 

The  terms  of  the  language  are  made  of  relation  variables  P,  Q,R,  etc.,  and  from 
subterms  s,  t,  etc.,  composed  with 

•  union  s  U  t  and  intersection  s  D  t:  these  correspond  to  the  set  union  and 
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intersection  of  the  relations  represented  as  sets  of  pairs; 

•  composition  sot,  also  called  relational  product; 

•  complement  s',  defined  with  respect  to  the  type  of  s,  giving  the  relation  of  the 

same  type  whose  pairs  are  all  those  not  in  s; 

•  inverse  s~. 

There  are  also  three  constants;  0  (the  empty  relation),  L  (the  universal  relation) 
and  I  (the  identity).  To  be  precise,  we  should  distinguish  instances  of  these 
constants  that  have  different  types,  but  it  is  easy  to  infer  the  types  from  the 
context,  so  we  shall  not  bother.  In  the  formula 

P  =  QoL 

for  example,  if  P  has  type  (S,  T)  and  Q  has  type  (S,  U),  then  the  appropriate  univer¬ 
sal  relation  L  has  type  (U,  T),  and  is  interpreted  as  the  cartesian  product  of  the  sets 
denote  by  U  and  T. 

Applying  the  ordering  c  to  terms  is  the  only  way  to  generate  elementary  formu¬ 
lae;  SQt  will  be  true  when  the  set  of  pairs  denoted  by  s  is  a  subset  of  the  set 
denoted  by  t.  The  ordering  is  antisymmetric,  so  s  =  t  when  set  and  t  e  s.  Finally, 
formulae  may  be  joined  by  the  logical  connectives.  A,  V,  and 

To  see  how  to  express  familiar  specifications  in  this  language,  note  that  a  subset 
M  of  a  set  X  can  be  represented  as  a  relation  on  X  X  Y  that  pairs  each  element  of  u 
with  every  element  of  Y.  A  relation  u  thus  denotes  a  set  if 

u  o  L  =  u. 

Similarly,  a  point  x  in  X  is  a  relation  on  X  X  Y  that  pairs  the  single  element  x  with 
every  element  of  Y.  A  relation  x  is  a  point  if 
x  =  x  o  L  A  X  o  x~  si  A  -’X  =  0. 

A  pair  of  points  (x,  y)  is  represented  by  the  relation 
X  o  y~ 

It  is  easy  to  write  formulae  that  classify  relations  in  the  manner  of  Z’s  type  declara¬ 
tions.  A  relation  R  is  total  if 
L  =  RoL 
and  a  function  if 
RoR~  cl 

It  is  surjective  if  its  inverse  is  total,  injective  if  its  inverse  is  a  function,  and  bijective 
if  it  is  injective  and  surjective. 

The  familiar  operators  of  Z  are  also  easily  defined.  The  domain  of  a  relation  R  is 
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just  R  o  L,  and  its  range  is  jR~  o  L.  The  domain  restriction  of  a  relation  Rto  a  set  S, 
written  in  Z  as  S  <  R,  is  SnR.  Relational  override  is  defined  by 

P©Q  =  (Pn(Q  oL)')uQ. 


4  A  Model  of  the  Relational  Calculus 

Reasoning  in  the  relational  calculus  can  be  conducted  purely  algebraically,  without 
appealing  to  any  concrete  representation  of  relations.  Since  our  purpose,  however, 
is  finding  counterexamples  -  concrete  values  of  variables  for  which  a  formula  does 
not  hold  -  the  representation  of  relations  is  critical. 

We  shall  start  with  a  conventional  model  of  relations.  The  meaning  of  a  formula 
fand  its  constituent  subformulae  and  terms  is  defined  with  respect  to  an  interpreta¬ 
tion  ([/,  T,  p)  consisting  of 

•  a  universe  U  of  values, 

•  a  mapping  t  that  associates  with  each  type  name  T  in  the  type  declarations  of  f 

a  set  tJT]]  s  U,  disjoint  from  the  set  tUSJ  associated  with  a  different  type 
name  S,  and 

•  a  mapping  p  that  associates  with  each  variable  R  of  type  (S,  T)mfa  set  of  pairs 

pPE  e  tIIS]]  X  tIITI. 

The  meaning  of  a  formula  is  defined  inductively  over  the  structure  of  the 
formula.  Consider  terms  first.  The  meaning  of  a  relation  variable  is  given  directly 
by  the  interpretation 

MPI]  =  pPD 

For  the  constants,  the  zero  relation  0,  the  identity  relation  Ij  of  type  (T,  T)  and  the 
universal  relation  of  type  (S,  T),  we  have 

MHO]]  =  0 

MllTl  =  {{x,x)\xeT\im 

The  complement  s'  of  a  term  s  of  type  (S,  T)  denotes  the  largest  relation  of  the 
same  type  that  includes  none  of  the  pairs  in  s 

MHs']]  =  {(x,  y)  e  t[[5]]  X  tUTH  j  (x,  y)  $  Hs]]} 

The  other  relational  operators  have  their  conventional  meaning: 

MHs  U  =  {(x,  y)  I  (x,  y)  6  MM  or  (x,  y)  e  MHt]]} 
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MUs  n  =  {(x,  y)  I  (x,  y)  6  MUsD  and  (x,  y)  6  Mp]]} 

MUs  o  =  {(x,  y)  I  3z.  (x,  z)  €  Mp]]  and  (z,  y)  €  Mp]]} 

M|Is~I]  =  {(y,x)  I  (x,  y)eM[IsI]}. 

The  ordering  on  relations  denotes  the  subset  ordering  on  their  pair  sets: 

Mils  C  ^I]  =  V(x,  y)  e  MM-  (x,  y)  e  Mpu 

And  finally,  the  logical  connectives: 

Mlf  A  gU  =  Mi/ll  and  MBgl 

M[lAvg]]=  MII/ll  or  MM 

Ml--f^  =  notMm 

Under  a  given  an  interpretation,  the  meaning  of  a  formula  is  either  true  or  false. 
If  it  is  true,  the  interpretation  is  said  to  be  a  model  of  the  formula;  if  it  is  false,  the 
interpretation  is  a  counterexample.  A  formula  that  has  a  model  is  satisfiable-,  a  for¬ 
mula  that  has  no  counterexamples  is  valid. 


5  A  Different  Model 

Consider  checking  the  formula 

-Peg  V  QoRq  PoR 

which,  were  P  and  Q  to  be  exchanged  in  one  of  the  subformulae,  would  express 
the  monotonicity  of  composition,  but  as  it  stands  is  not  valid.  One  counterexample 
maps  P  to  the  empty  relation,  Q  to  the  singleton  {{a,  b)}  and  R  to  {{b,  c)}. 

Mapping  P  instead  to  {{a,  b))  does  not  give  a  counterexample. 

Suppose  we  are  enumerating  interpretations  in  a  search  for  counterexamples, 
and  we  generate  this  latter  interpretation  first.  Generating  values  for  R,  we  might 
then  consider  {{a,  c)}.  This  is  guaranteed  not  to  be  a  counterexample  for  a  simple 
reason:  the  second  element  of  the  pair  is  irrelevant,  and  cannot  affect  the  meaning 
of  the  second  subformula.  In  general,  any  permutation  of  the  range  elements  of  R 
will  preserve  the  meaning  of  the  formula.  What  matters  here  is  the  matching  of  the 
ranges  P  and  Q  to  the  domain  of  P;  the  counterexample  that  maps  P  to  {{b,  c)} 
works  because  b  matches  the  second  element  of  the  pair  in  Q  but  no  second 
element  in  P,  and  thus  distinguishes  Q  and  P. 

This  suggests  that  to  exploit  such  symmetries  we  should  focus  not  on  the  values 
of  the  elements  in  relations’  pairs,  but  in  the  mappings  between  them.  We  therefore 
define  a  new  kind  of  interpretation.  First,  we  must  distinguish  the  occurrence  of  an 
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element  in  different  places-,  the  range  elements  of  R  in  the  example  above  must  be 
disjoint  from  the  domain  or  range  elements  of  P  or  Q  so  that  we  can  refer  to  them 
independently.  To  do  this,  we  label  each  occurrence  of  a  type  name  T  in  the  type 
declarations  with  an  index  to  distinguish  it  from  other  occurrences  of  the  same 
name.  For  example  the  declarations 

P:  (S,  5) 

Q  -.  (T,  U) 

R:  {S,  Tj 

would  be  transformed  to 

P:  iSi,S2) 

Q:  (Ti,  Ui) 

R:  {S3,  T2) 

A  wired  interpretation  {U,  t,  p,  W)  of  a  formula  /"whose  type  declarations  have 
been  transformed  in  this  manner  consists  of: 

•  a  universe  U  of  values,  as  before, 

•  a  mapping  t  that  associates  with  each  type  name  Tj  in  the  type  declarations  of  f 

a  set  tUT,]]  c  U.  These  sets  must,  as  before,  be  disjoint;  furthermore,  sets  tUT,]] 
and  rUTy]]  associated  with  two  type  names  that  differ  only  in  their  index  must 
have  the  same  cardinality, 

•  a  mapping  p  that  associates  with  each  variable  R  of  type  (S,  T)  in  /a  set  of  pairs 

pUP]]  e  tUSJ  X  t[I7T],  as  before,  and 
■  an  additional  component  W. 

W  is  called  the  wiring.  It  is  an  equivalence  relation  on  U  with  the  following 
property: 

•  for  each  x  in  tUT,]]  there  is  exactly  one  y  in  each  set  rUTy]],  and  no  z  in  any 

such  that  xWy 

where  S  and  T  are  distinct  type  names.  Intuitively,  W  matches  elements  in  different 
places  that  have  the  same  value  in  the  underlying  type. 

Operators  on  a  single  relation,  and  the  logical  connectives,  are  interpreted  just  as 
before.  The  meaning  of  a  term  involving  two  relations,  however,  now  depends  on 
the  wiring;  where  equality  appeared  in  the  definition  before,  the  wiring  equivalence 
W  now  takes  its  place. 

MUs  U  ?]]  =  {(x,  y)  I  (x,  y)  6  MUsJ  or  3  (x',  y')  6  Mp]].  xWx'  and  yWy'} 

M[[s  n  =  {(x,  y)  I  (x,  y)  6  Mp]]  and  3{x',  y')  E  M[[t]].  xWx'  and  yWy'} 

M[[s  o  =  {(x,  y)  I  dz,  z'.  (x,  z)  E  MUs]  and  zWz'  and  {z',  y)  E  Mp]} 
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Likewise,  the  subset  predicate  is  relative  to  the  wiring: 

Mis  c  ^]]  =  V(x,  y)  e  MUsJ.  3{x',  y')  £  Mpl.  xWx'  and yWy' 

Note  that  the  meanings  of  union  and  intersection  are  no  longer  symmetrical  in 
their  arguments.  The  term  s  U  ^  has  the  type  of  s.  It  might  instead  have  the  type  of 
t,  or,  perhaps  more  naturally,  a  new  type  that  is  the  union  of  the  types  of  s  and  t.  It 
turns  out,  however,  to  be  simpler  not  to  introduce  new  types,  and  the  decision  to 
use  s’s  type  is  arbitrary.  As  a  result,  it  is  no  longer  obvious  that  union  is 
commutative.  The  terms  sVt  and  t  U  s  will  in  general  have  different  meanings; 
however,  any  pair  (x,  y)  in  one  will  match  a  pair  {x',  y')  in  the  other,  with  xWx'  and 
yWy',  so  that  we  will  have 
fUscsU? 
and 

s  U  t  c  ^  u  s 
as  expected. 

We  shall  call  a  wired  interpretation  of  a  formula  f  for  which  f  is  false  a  wired 
counterexample  of  f. 


6  Scopes,  Permutations  and  Adequate  Assignment  Sets 

In  general,  a  formula  will  have  an  unbounded  number  of  interpretations,  because 
one  or  more  of  the  basic  types  will  be  infinite.  It  is  therefore  necessary  to  limit  the 
search  for  a  counterexample  to  some  finite  subset  of  the  interpretations.  We  would 
like  to  do  this  systematically,  rather  than  by  just  selecting  arbitrary  interpretations. 

A  search  is  conducted  within  a  scope,  which  assigns  a  natural  number  to  each 
type  name  representing  a  bound  on  the  number  of  values  of  the  type: 

scope:  type  — ►  Nat 

A  wired  interpretation  must  map  two  type  names  differing  only  in  index  to  sets  of 
the  same  cardinality,  so  any  scope  must  assign  the  same  value  to  both.  We  shall 
therefore  not  distinguish  the  conventional  scope  from  the  wired  scope,  since  each 
can  be  obtained  trivially  from  the  other. 

For  a  scope  s,  we  shall  say  that  a  type  assignment  t  is  adequate  if  it  maps  each 
type  name  T  to  a  set  whose  cardinality  is  at  least  s{T).  If  for  any  type  assignment  t 
over  universe  U  that  is  adequate  for  a  scope  s  there  is  a  variable  assignment  p  such 
that  a  formula  fis  false  under  the  interpretation  (U,  t,  p) ,  we  shall  say  that  /  has  a 
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counterexample  in  the  scope  s. 

For  any  formula,  there  is  some  set  of  possible  assignments  of  relation 
variables  to  relation  objects.  Since  the  wiring  relation  effectively  permutes  these  ob¬ 
jects,  not  all  assignments  will  be  needed.  In  enumerating  the  possible  values  of  a  re¬ 
lation  variable,  out  of  a  set  of  isomorphic  relations  only  one  is  required,  and  this 
representative  may  be  selected  arbitrarily. 

A  permutation  tt  is  a  bijection  on  a  finite  set  X 

7r:X-»X 

and  may  be  applied  pointwise  to  a  relation 
r  c  S  X  T 

Tr(r)  =  {{n{a),  nib))  \  {a,  b)  E  r) 

if  it  preserves  the  relation’s  type,  so  that  Trfr)  c  S  X  T.  To  ensure  this,  we  require 
first  that 
X=SUT 

and  second  that  the  permutation  tt  be  expressible  as  the  union  of  separate  permuta¬ 
tions  on  the  relation’s  domain  and  range;  that  is 

TT  =  TTj  U  TT2 
where 
TTf.  S—*  S 

A  permutation  can  be  applied  pointwise  to  an  assignment  p  under  analogous  condi¬ 
tions:  the  domain  of  the  permutation  must  be  the  union  of  the  domains  and  ranges 
of  the  relations  in  p,  and  the  permutation  must  be  decomposable  into  permutations 
that  do  not  confuse  types.The  result  of  applying  a  legal  permutation  tt  to  an  assign¬ 
ment  p  is 

IT  {fi)  =  {v'-^  n{r)  I  r  G  p} 

Two  relations  r  and  s  are  isomorphic,  written  r  «  s,  if  there  is  a  permutation  tt 
such  that 
n{r)  =  s 

and  two  assignments  p  and  p'  are  isomorphic,  p  ~  p',  if  there  is  a  permutation  tt 
such  that  TT  (p)  =  TT  (p').  Because  the  types  of  the  individual  relations  in  a  wired  in¬ 
terpretation  are  disjoint,  a  permutation  on  an  assignment  can  always  be 
decomposed  into  elementary  permutations  on  individual  relations.  It  follows  that 
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two  assignments  are  isomorphic  when  their  constituent  relations  are  pointwise  iso¬ 
morphic. 

Given  a  type  assignment  r  adequate  for  some  scope  s,  a  set  of  variable 
assignments 

~  {Pli  P2’  •••’  Pn^ 

is  adequate  if  every  variable  assignment  p  that  respects  t  is  isomorphic  to  some  as¬ 
signment  in  JA.  Now  comes  the  crucial  justification  for  the  notion  of  wiring: 

Theorem  1 .  Suppose  t  is  an  adequate  type  assignment  over  a  universe  U  for  a 
formula  fin  a  scope  s.  Let  JK  be  an  adequate  set  of  variable  assignments.  Then 
fhas  a  counterexample  in  the  scope  s  exactly  when  it  has  a  wired 
counterexample  (U,  t,  p,  W)  for  some  variable  assignment  p  6  JT  and  wiring 

W. 

In  other  words,  varying  the  wiring  relation  achieves  the  same  effect  as  permuting 
the  relations  of  the  assignment.  Instead  of  checking  all  assignments,  we  can  pick  an 
adequate  set  that  embodies  all  assignments  of  variables  to  ‘shapes’  and  then 
enumerate  all  wirings  of  these  shapes.  The  benefit  of  this  complication  is  that  the 
permuting  of  relations  has  been  localized  in  the  wiring  relation,  where  symmetry 
can  be  exploited  more  simply. 


7  Symmetry  in  Assignments  and  Wiring  Relation  Equivalences 
A  permutation  rr  that  leaves  an  assignment  p  invariant 

p  =  jx(p) 

is  said  to  be  a  symmetry  of  p.  Remember  that  rr  acts  on  the  elements  of  the  universe 
U;  it  may  be  applied  pointwise  to  the  relations  of  p  only  when  it  does  not  exchange 
elements  of  one  variable’s  relation  with  elements  of  another’s,  or  elements  of  a  re¬ 
lation’s  range  with  its  domain.  The  symmetries  of  an  assignment  p  form  a  group 
under  functional  composition  called  the  symmetry  group  of  p. 

Now  suppose  we  apply  the  same  permutation  tt  to  some  wiring  W  (without  the 
constraint,  since  W  is  symmetric  and  tt  will  thus  inevitably  confuse  its  domain  and 
range).  Over  any  pair  of  type  sets,  W  is  bijective,  so  unless  tt  permutes  elements  in 
both  sets  in  the  same  way,  it  cannot  be  a  symmetry.  Nevertheless,  even  though  vW 
^  W,  the  meaning  of  the  formula  under  the  wiring  ttW  must  be  the  same  as  the 
meaning  under  W: 
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Theorem  2,  If  tt  is  a  symmetry  of  p  then  ([/,  t,  p,  W)  is  a  wired  counterexample 
of  a  formula  /  exactly  when  (U,  t,  p,  Tr(W))  is. 

Consequently,  not  all  wirings  need  be  consided  for  every  assignment.  Two 
wirings  W  and  W'  are  equivalent  for  an  assignment  p  if  there  is  a  symmetry  rr  of  p 
such  that  W'  =  n{W),  From  each  equivalence  class  of  wirings,  only  one  wiring  is 
needed,  and  it  can  be  picked  arbitrarily. 


8  Generating  Wirings 

A  wiring  relation  only  matches  elements  that  belong  to  the  same  underlying  type, 
so  it  can  be  decomposed  into  a  collection  of  relations,  one  for  each  type.  Each  of 
these  relations  wires  the  elements  of  the  sets  t[1TjI],  t[1T2I],  tUT^J,  etc.,  correspond¬ 
ing  to  the  underlying  type  T;  between  any  pair  of  these  sets  rUT^l]  and  the  re¬ 
lation  is  bijective.  The  wiring  relation  is  the  union  of  these  individual  relations. 

Ignoring  symmetry  then,  a  full  set  of  wirings  can  be  generated  by  taking  all  com¬ 
binations  of  individual  wirings.  These  are  enumerated  as  follows.  Imagine  the  sets 
tIITjE,  etc.,  laid  out  in  a  row  so  that  each  occupies  a  vertical  column. 
Take  the  first  element  of  the  first  column.  This  may  be  matched  to  any  of  the 
elements  in  the  second  column,  and  then  to  any  element  of  the  third,  and  so  on. 
Each  sequence  of  choices  yields  a  path  through  the  full  graph  that  connects  every 
element  in  to  every  element  in  t[1T2I],  every  element  in  t[1T21I  to  every 

element  in  tHTjI]  and  so  on,  the  path  itself  being  a  matching  of  one  element  in 
tJT^I]  to  one  element  in  each  of  the  other  tUT,!]. 

For  each  of  these  paths,  we  now  determine  the  set  of  paths  that  start  at  the 
second  element  in  the  first  column  but  none  of  which  overlap  with  the  path  from 
the  first  element.  Repeating  this  procedure  until  no  paths  remain  gives  a  tree, 
whose  ith  level  represents  the  choice  of  path  from  the  ith  element  of  the  first 
column.  The  leaves  of  the  tree  then  give  the  wirings,  each  being  obtained  by  form¬ 
ing  a  relation  from  the  tuples  at  each  the  nodes  on  the  path  (this  time  the  tree  path) 
from  the  root  to  the  leaf. 

Symmetry  allows  some  of  these  wirings  to  be  omitted.  Theorem  2  tells  us  that 
having  generated  a  wiring  w  we  should  not  subsequently  generate  a  wiring  tt{w)  if 
TT  is  a  symmetry  of  the  variable  assignment.  In  the  enumeration  algorithm,  this  is 
avoided  by  noting  that  two  paths  p  and  p'  such  that  p'  =  n{p)  are  equivalent,  and 
only  one  should  be  generated. 
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The  equivalence  of  paths  is  not  determined,  of  course,  by  attempting  to  find  a 
suitable  permutation.  Instead,  for  each  variable  assignment,  the  elements  of  the 
universe  U  are  partitioned  into  equivalence  classes.  Given  any  element  u  €  U,  and 
variable  assignment  p,  the  orbit  of  u  is  the  set  of  elements  that  are  obtained  by 
applying  to  it  some  permutation  that  is  a  symmetry  of  p: 

orbit  {u,  p)  =  {tt(m)  |  3tt.  n{p)  =  p} 

Since  the  symmetries  of  p  form  a  group,  belonging  to  the  same  orbit  is  an 
equivalence  relation  and  the  orbits  partition  the  universe.  The  symmetries  of  a  vari¬ 
able  assignment  may  thus  be  represented  as  a  colouring  function  that  maps 
elements  of  U  to  orbits; 
colour:  U  — ►  Orbit 

Two  paths  a  and  b  are  equivalent  when  their  respective  elements  belong  to  the 
same  orbit: 

eguiu  ((aj,  aj, ...,  a„},  {b^,  b2, b„))  =  V/;  l..n.  colour  {a^  =  colour  (fe,) 

The  equivalence  check  ensures  that,  having  built  a  partial  wiring,  the  algorithm 
does  not  generate  completions  that  differ  immediately  in  the  choice  of  the  next 
path  selected,  when  those  paths  are  in  fact  equivalent.  But  unnecessary  wirings  may 
still  be  constructed  because  two  paths  may  be  selected  in  different  orders.  To  rule 
this  out,  we  pick  any  ordering  on  orbits 

<:  Orbit  Orbit 

extend  it  lexicographically  to  paths 

p<p'  =  first  (p)  <  first  ip')  V  {first  (p)  =  first  ip')  A  rest  ip)  <  rest  {p')) 

and  require  that  paths  always  be  generated  in  order.  Having  generated  a  path  p, 
subsequent  choices  p'  at  the  same  level  of  the  tree  must  satisfy  p  <  p',  and 
subsequent  choices  at  lower  levels  of  the  tree  must  satisfy  p  <  p'. 

One  detail  remains:  how  the  orbits  are  determined.  Remember  that  no  permuta¬ 
tion  exchanges  elements  of  one  relation  with  elements  of  another.  So  the  orbits  of 
the  elements  of  each  relation  in  the  assignment  can  be  determined  independently. 
Our  prototype  checker  constructs  the  assignments  from  a  fixed  repertoire  of 
relation  values  that  are  bound  to  variables  in  all  possible  combinations.  Each 
relation  value  is  stored  along  with  its  symmetries.  Suppose,  for  example,  we  have  a 
relation 
r:  (S,  T) 

and  a  type  assignment  t  with 
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tUSB  =  {1,2,3} 
rm  =  {4,  S,  6} 

Some  values  r  might  take,  along  with  their  symmetries,  are: 

relation  domain  symmetry  range  symmetry 

{}  {{2,2,3}}  {{4,5,6}} 

{(2,4)}  {{2},  {2, 3}}  {{4},  {5, 6}} 

{(1,4),  (1,5)}  {{2},  {2,3}}  {{4,  5},  {6}} 

The  second  and  third  columns  give  the  orbit  partitionings  for  tUS]]  and  tUT]].  The 
colouring  function  is  trivially  obtained  from  these  partitionings.  Using  letters  of  the 
alphabet  to  label  orbits 
Orbits  =  {A,  B,  C, ...} 


these  relations  might  give: 


relation 

{} 

{(2,4)} 
{(2,4),  (2,5)} 


colouring  function 
{2  ^A,2^A,3y^ 
{1^A,2^B,3^ 
{2  •-+ A,  2  '-*■  B,  3  ► 


A,  4 

B, 4 
B,4 


D,5>^D,6^D} 
D,5^E,6^E} 
D,5  ^D,6^E}. 


9  Discussion 

Existing  checking  methods  fall  into  two  classes.  Those  aimed  at  proving  properties 
of  specifications  cannot  be  automatic,  since  any  interesting  property  of  a  system 
whose  states  are  unbounded  is  undecidable.  Theorem  provers  have  been  used 
successfully  to  verify  some  substantial  designs,  but  in  all  cases  they  require  users 
with  the  mathematical  sophistication  to  invent  lemmas  and  proof  strategies,  and  a 
lot  of  time  to  spare.  For  safety  critical  systems,  the  investment  may  be  worthwhile, 
but  for  routine  design  work  something  more  economical  is  called  for. 

The  second  class  of  checking  methods  is  more  pragmatically  motivated.  The 
specification  is  ‘animated’  by  calculating  the  behaviour  resulting  from  specified  ini¬ 
tial  conditions.  Such  execution  typically  requires  that  the  specification  be  written  in 
a  constructive  form  without  implicit  definitions.  The  IFAD  tool  for  VDM  [ELL94, 
LL91],  for  example,  can  execute  explicit  function  definitions,  even  when  they  con¬ 
tain  non-deterministic  constructs.  Z"  [Val91]  is  a  subset  of  Z  that  requires 
equalities  to  be  ordered  with  constructive  expressions  on  the  right-hand  side  so 
they  can  be  interpreted  as  assignments.  (Z"  is  not,  incidentally,  intended  as  a  speci- 
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fication  language  but  as  a  target  for  refinement  of  Z.)  Aslantest  [DK94]  embodies 
an  interesting  hybrid  approach:  the  specification  can  be  executed  not  only  over  test 
cases,  but  also  over  symbolic  initial  conditions.  The  result  of  a  symbolic  execution 
is  checked  against  a  specified  final  condition  using  a  simplifier,  which,  if  always  to 
^  succeed,  must  be  a  theorem  proven 

Animating  a  specification  suffers  from  the  same  basic  problem  as  testing.  When 
the  state  space  is  huge,  testing  a  small  number  of  cases  is  very  unlikely  to  uncover 
c  faults.  Counterexamples  usually  correspond  to  combinations  the  designer  never 

considered,  and  would  probably  have  omitted  from  a  test  suite.  It  is  not  that  testing 
cannot  show  the  absence  of  errors;  it  often  fails  to  show  their  presence. 

The  approach  described  here  falls  into  neither  class.  Like  animation,  it  is  partial, 
but  since  the  states  within  the  scope  are  enumerated  automatically,  no  specification 
of  test  cases  is  required.  Consequently,  the  number  of  cases  examined  is  orders  of 
magnitude  greater  -  100,000  cases  is  not  a  large  model  checking  problem  -  and 
more  likely  to  include  unanticipated  counterexamples.  Like  theorem  proving,  the 
checking  method  is  designed  for  fully  implicit  specifications,  without  demanding  a 
translation  into  an  executable  subset. 

Counterexample  generation  lacks  the  mathematical  cachet  of  proof,  but,  in  engi¬ 
neering  terms,  it  has  an  advantage.  A  counterexample  has  a  value  quite 
independent  of  the  specification  from  which  it  arose.  A  designer  might  be  pleased 
that  his  design  has  been  formally  modelled  and  proven  consistent,  but  might  have 
doubts  about  the  fidelity  of  the  model.  A  counterexample,  in  contrast,  can  be 
immediately  put  to  the  test;  if  it  reveals  an  error  in  the  actual  design,  the  model  no 
longer  matters. 

Symmetry  has  been  used  before  to  reduce  state  space  search,  but  not,  it  seems,  in 
the  fine-grained  fashion  proposed  here.  Clarke,  Filkorn  and  Jha  show  how  global 
symmetries  of  the  transition  relation  can  be  exploited  [CFJ94].  The  state  machine 
representing  a  protocol  that  coordinates  the  caches  of  several  processors,  for  exam¬ 
ple,  might  be  symmetric  under  the  exchanging  of  one  processor  for  another  or  one 
cache  line  for  another.  With  knowledge  of  these  symmetries  (provided  to  the 
checker  by  the  user),  a  quotient  machine  can  be  constructed  with  fewer  states  than 
the  original  machine,  each  representing  a  set  of  states  that  are  equivalent  under 
symmetry.  Z  specifications  do  not  seem  to  have  global  symmetries  of  this  sort. 
Instead,  we  exploited  the  symmetry  of  one  possible  relation  value  a  variable  may 
take,  in  order  to  reduce  the  set  of  states  obtained  by  varying  the  values  of  other 
-r  variables.  Note  also  that  we  never  required  any  symmetries  to  be  specified  by  the 

user:  they  are  inferred  by  the  tool  from  the  symmetries  of  the  underlying  relation 
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shapes. 

The  checking  method  has  been  implemented  as  a  prototype  in  Standard  ML  of 
New  Jersey.  It  was  built  for  proof  of  concept,  to  demonstrate  that  symmetry  can  be 
used  to  reduce  the  search  space,  and  thus  provides  none  of  the  features  a  usable 
tool  would  require.  For  example,  the  decomposition  of  the  wiring  relation  must  be 
specified  by  the  user,  and  referenced  explictly  in  the  formula.  The  prototype  also 
runs  absymally  slowly:  it  examines  about  5,000  states/minute  on  a  Sparc  5.  We  plan 
now  to  construct  a  usable  tool  (in  C).  It  will  read  specifications  in  a  subset  of  Z  and 
derive  the  structure  of  the  wiring  relation  automatically.  It  will  allow  the  user  to  ex¬ 
periment  with  different  scopes,  constructing,  for  each,  a  set  of  appropriate  relation 
values  along  with  their  symmetries.  Furthermore,  it  will  offer,  for  each  relation 
variable,  the  choice  of  restricting  its  values  to  functions,  injections,  bijections,  etc. 

Much  research  remains  to  be  done.  Quantifiers  and  higher-order  relations  are 
not  currently  handled,  nor  are  interpreted  types  (such  as  the  integers).  Also,  a  lim¬ 
ited  form  of  type  inference  may  be  required.  If  a  formula’s  type  declarations  are 
unnecessarily  restrictive,  the  wiring  relation  will  not  be  decomposed  as  much  as  it 
might  be,  and  the  resulting  search  will  be  larger.  For  example,  the  formula 

dom  (p  o  q)  Q  dom  p 

does  not  require  the  domain  of  p  and  range  of  q  to  have  the  same  type.  The  type 
declaration 

p:  {S,  T) 
q:  (T,  S) 

would  give  wirings  that  enumerate  all  bijections  between  the  domain  of  p  and 
range  of  q,  even  though  their  relationship  is  irrelevant.  The  type  declaration 

p:{S,T) 

q:  iT,R) 

on  the  other  hand,  gives  wirings  that  relate  only  the  range  of  p  and  domain  of  q. 
This  divides  the  size  of  the  search  by  the  factorial  of  scope{S). 

The  fundamental  premise  of  the  checking  method  described  here  is  radical  but 
simple  minded:  that,  in  practice,  errors  in  specifications  can  be  detected  by  system¬ 
atically  exploring  even  a  tiny  portion  of  the  state  space.  Exploiting  symmetry  can 
reduce  the  search  dramatically,  but  it  seems  unlikely  that  the  exponential  nature  of 
the  problem  will  be  overcome.  This  is,  perhaps,  only  a  theoretical  concern.  If  con¬ 
stant  factors  gained  by  search  reduction  strategies,  by  succinct  representations  and 
by  faster  hardware  bring  the  analysis  of  realistic,  industrial  designs  within  reach,  as- 
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ymptotic  complexity  will  surely  be  irrelevant. 
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